✅ Deploy Preview for fakerjs ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	2d3cf1a
🔍 Latest deploy log	https://app.netlify.com/projects/fakerjs/deploys/69d3edbce67fab00080b35a6
😎 Deploy Preview	https://deploy-preview-3467.fakerjs.dev
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.89%. Comparing base (eba7d99) to head (2d3cf1a).

@@           Coverage Diff           @@
##             next    #3467   +/-   ##
=======================================
  Coverage   98.89%   98.89%           
=======================================
  Files         887      887           
  Lines        3064     3064           
  Branches      556      556           
=======================================
  Hits         3030     3030           
  Misses         30       30           
  Partials        4        4           

zh_TW (Taiwan) also only includes a subset of common surnames, and it works quite well. so I think zh_CN could do the same — weighting may not be necessary (consider generic_common is not a module type). just removing the rare surnames and keeping the common ones might be enough.

If you're aligned with this idea, I'm happy to submit a PR for the change (pick surnames), which would only change the locals.

I'm not 100% sure this is the best approach (versus just using common surnames) though I'd say the fact that generic_common is not in the module definition is not enough to disqualify it as an approach, there are plenty of other edge cases in the locales which use non-standard keys.

For example company.legal_entity_type and company.category used in various definitions and locales.

For me, both weighting and/or reducing the number of rare last names in that list are valid sulutions.

Looks like you have to run preflight on this PR once more.